One of the most important stages in the software development cycle is the debugging stage that occurs after a software product has shipped. This stage is important because the experiences of millions of users of the software product may be utilized during this stage to isolate program errors, identify frequently or infrequently used features, and to generally make the software product better. In order to capitalize on the body of user experience with the software product, however, it is necessary to obtain data from users and to route this data to the software developer.
Prior to the widespread adoption and use of the Internet, it was very difficult for software developers to obtain quality data regarding how a software product performs for a large number of users. Now, however, the Internet connects millions of users with the developers that create and debug the software they use. The Internet, therefore, allows data regarding the operation of a software product to be sent from a computer user to the developer of the product. The data may then be utilized by the developer to fix errors, also called “bugs,” in the program, to change the way the program operates by adding or removing features, and to otherwise improve the program. However, current systems for transmitting this data from a user to a software developer suffers from several drawbacks that reduce their effectiveness.
Current systems for reporting data regarding the operation of a software product generate event reports in response to the occurrence of an event within program code. For instance, an event report may be generated when an error occurs in the program code, when an unhandled exception is generated by the program code, when a particular line of code is encountered, or under other circumstances. Data that may assist the developer in understanding the event and in modifying the program code to ensure that it does not occur again is typically included in the event report. For instance, data describing the state of the computer when the event occurred may be included along with other data in the event report.
Current systems for reporting data regarding the operation of a software product suffer from several serious drawbacks that limit their effectiveness. In particular, current reporting systems require that data describing any type of event be formatted in a manner compatible with a schema for describing program crashes, or require that a custom error type be defined for each type of event. Forcing all types of events to utilize a schema for program crashes is very limiting. For example, a software developer that needs more than the number of parameters utilized to describe crashes, or needs to utilize more data than allowed by the parameters, must somehow work around this limitation. Moreover, backend systems for mining the event data may not operate correctly on data for a non-crash event that is forced into a schema for describing program crashes. This makes it very difficult for a developer to filter the desired event data from the large body of program crash information.
Creating a custom error type for each event to be reported is also a less than desirable solution. Creating a custom error type for each event requires a substantial amount of work. In particular, this process includes creating custom software components for receiving the reports, defining and storing custom tables in a database, and creating custom Web pages and other components for viewing the data. Because of the complexity and amount of work required to create these tools, it is difficult to provide quality software components for viewing all types of events. As a result, the data generated in response to the occurrence of events is under-utilized. Alternatively, because of the difficulty involved, a custom solution may not be created.
It is with respect to these considerations and others that the present invention has been made.